Hmm so if we only expect a 5% improvement in import time I am actually -1 on this change. I don't think its worth adding runtime logic for a small optimization

Can you add these modules to the blacklist in ci/code_checks.sh?

Looks like it checks for e.g. "urllib" as opposed to "urllib.request". Since we also import urllib.parse, we can't exclude that. Excluding "http" works though.

so if we only expect a 5% improvement in import time

Some context on that number:

• PERF: lazify pytz seqToRE call, trims 35ms from import #28228 gets another 5% or so
• numpy master (but not 1.17) makes numpy.testing import lazy, trimming about 15% from their import time, so about 3% of ours
• IIRC before long we'll stop importing matplotlib at import-time, which could trim our time by up to 20% (based on current timing of pandas.plotting._matplotlib import)

The 5% we get here becomes a bigger deal as those get whittled down

trimming import time is always good; sure it sometimes makes the code a bit more complex but +1 here

I'm ok with this, especially on the aggregate benefits, but suspect it will be brittle, as someone could in the future (unaware) undo this optimization, so we only get left with the complexity, and no benefit. Maybe add tests for the content of sys.modules in a seperate CI run?

Does the code check added not catch that?

Ah nevermind - I see that is only for the http module not urllib

Im also thinking more general, imports in imported modules etc.

We could modify the check. I don't know why I originally wrote it to just check the package.

edited code check

Wouldn't it make sense to have a whitelist instead of a blacklist? A blacklist will allow a lot of things that we might not really want when importing pandas.

Let's leave the idea of a whitelist changeover for a separate discussion. Other than that, I think everything has been addressed here.

A merge of master should fix CI.

can you rebase

Rebased +green

Thanks.